IBIS Macromodel Task Group Meeting date: 19 April 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: * David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: * Steve Parker Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Walter noted that he had prepared a presentation on how referencing affects the receiver threshold parameters. - Arpad noted that Curtis had informed him that he would not be able to attend the meeting on April 26th. Arpad said that we would need someone else to take the minutes. Randy Wolff said he would be able to attend and could take the minutes. ------------- Review of ARs: - Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. - In progress. Arpad noted that Ambrish was unable to attend the meeting, but that he had emailed Arpad a new draft of BIRD 147. The draft was not quite ready for posting, but will be ready soon. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Walter: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: New Redriver Flow: - Fangyi: [sharing his updated "AMI Simulation Flow Round 3" version 3] - I've updated the presentation based on the feedback from the last meeting. - The changes are not substantial, but they address the comments people made with regard to clarifying the presentation. - [Slide 4: Conventions (a new slide)] - Definitions: - "Normal flow" means a channel with no repeaters. - "Redriver flow" means the channel has redrivers. - Red/Blue/Green boxes: - Left side (inputs) - Red is the partial or local IR. - Blue is the total IR. - Right side (outputs) - Corresponding IRs returned by Rx Init(). - [Slides 5 - 10 (the various flows)] - Dashed vertical line in the middle, and an arrow indicating left to right as the direction from inputs to outputs. - Input IRs noted on the left of the dashed line. - Output IRs noted on the right of the dashed line. - Slide titles modified to avoid confusion about scenarios, for example: - "Normal Time Domain Flow: GetWave Tx" --> changed to --> "Normal Time Domain Flow: If Tx has GetWave" - Time domain cases more clearly labeled: - "Same as current flow" noted wherever appropriate. - "Same as current input|output impulse" noted wherever appropriate. - Walter has suggested keeping the crosstalk IRs as originally proposed. - Walter suggested having the model return just the CTLE IR in the red box output. - I have not made that modification yet. - Fangyi: I want to ask Walter and everyone about the parameter used to control this new flow. - Discussion: The group discussed various options, but converged on Walter's suggested implementation. If the model supports this enhanced flow, then the new Reserved parameter would appear in the .ami file with: - Type: Boolean - Usage: In - Format: List (false true) - Default: false If the model does not support the enhanced flow, then the parameter would not appear in the .ami file, or, if it did appear, the list would only contain the entry false. Several people asked if we could just use Format Value, but Walter noted that Value would only allow one value to be specified by the .ami file, it would not allow the user/tool to make a choice. Radek noted that the list parameter might allow the user to make a choice that was inconsistent with what the tool could actually do, and that it would fall to the tool to make the right choice. But he still felt the proposed solution was fine. Walter noted that since this was a Reserved parameter we could define any necessary special handling requirements. Mike L. suggested that it might be bad practice to use one variable to communicate something in two directions. Walter stated that the parameter was advertising what the model's capabilities were so that the user/tool could make a choice, and thus it was not a two way communication. Fangyi asked if a model could support only the new flow, and would therefore have a list containing only the entry true. Walter thought we should make that illegal. Fangyi expressed some more concern about the user having the ability to choose the wrong setting relative to what their tool could actually do. Walter agreed that this could be a source of trouble. Radek noted that this feature would be handled subject to the AMI_version number, so tools should be able to figure out the proper handling. Referencing and Ground: - Walter: [sharing his new presentation "Receiver Thresholds Assume GND=0.0V=Node 0"] - Discussion: Walter said that he had put forth the idea that IBIS is a specification that defines measurement conditions for a device under test. He said others had then pointed out that the [ISSO_xx] keyword descriptions did contain some definition of how a device in action (rails fluctuating) should behave. This led him to investigate further. He found that Node 0 was implicitly assumed by the way in which [Receiver Thresholds] specified how thresholds should vary when voltages applied to the rails varied. The presentation reviews the "A fully specified single-ended 3.3V CMOS receiver:" example found on pages 44 and 45 of the IBIS 6.1 specification. The example is based on device under test conditions with the gc_ref at the [GND Clamp Reference] value of 0V and the pc_ref at the [POWER Clamp Reference] value of 3.3V. Slide 5 of the presentation shows how the thresholds would be shifted if pc_ref were instead held at 3.8V. Slide 6 shows that the same threshold values are predicted by the [Receiver Thresholds] computations if gc_ref is also increased by 0.5V. That is, with gc_ref at 0.5V and pc_ref at 3.8V, the thresholds computed are nonsensical because they should simply be shifted by 0.5V since all the rails were shifted by 0.5V. The [Receiver Thresholds] Reference_supply sub-param can only specify one supply rail that the thresholds track. In this example it is the pc_ref rail, so the fluctuation in gc_ref is not accounted for and produces this nonsensical result. - Walter: In general, how do you interpret receiver thresholds? - This is a classic example of the reference node we are missing throughout IBIS. - If we can decide how this is supposed to work, then we can do a better job in the editorial change to the document. - Or, we just say ground is in fact Node 0 is 0. - For power aware simulations you would then have to use the ground referencing system that Scott noted is an option. - Arpad: I have to think about this carefully. - I want to again comment on the basic [Voltage Range] only case. That is a case where we are only specifying the difference between the pu_ref and the pd_ref of the device. We don't care where it is actually located in the universe (whether the ground pin is at 0, 1000V, etc.). - This situation is a clear indication to me that what we failed to write down in the IBIS spec is that those thresholds were probably referenced to something on the die, not outside the die. - Radek: This is a good catch by Walter. - I think the formula is flawed, and we should look at how it should behave. - I'm not sure how often it's used, but it is doubtful that calculation is right. - If everything is shifted, you should get what you expect (threshold properly shifted). - Walter: What Bob has said, correct me if I'm wrong, is that if you have the situation with gc_ref at 0.5V and pc_ref at 3.8V, then you have to create another [Model] for those conditions and use a [Model Selector] so the user can choose between 0 - 3.3V or 0.5 - 3.8V. - Bob: That's correct if you really want to shift things around by 0.5V. - These parameters were defined to map into certain DDR3 and DDR4 parameters. - They're defined with the expectation that this is CMOS with gc_ref at 0. - Not sure if the shifted case would be realistic. - Your points are well taken. - All of the reference rails might supply some actual effects in thresholds. - But when the modulations get extreme, and 0.5V at the gc_ref might be extreme, then that shouldn't be realistic in real designs. - Radek: If properly defined, that formula could have included the differences in both rails when they happen. But it doesn't. - Bob: We have an existing syntax. It has been used. - What you're illustrating is what an EDA tool will do with this data if it externally drives the buffer with a different voltage. - In your case, if the buffer is truly shifted then the 1.5V threshold will become 2.0V. The EDA tool can sort that out. - Walter: My point in all of this: - Here's another place where we make an assumption that ground is Node 0. - It's okay to say that for a DUT. - As soon as you're doing a power aware simulation and the ground node is floating then you cannot use any IBIS thresholds reliably. - The easy way out is to accept that IBIS is consistent if you're in a ground referenced system. - You just supply 0V wherever you have a gc_ref. - Simulation is really only modulating supply voltages like pc_ref. - The implication for interconnect is that it becomes okay to use Node 0 as the reference node for w-lines and touchstone files. - As soon as you get away from that and have floating gc_ref, do we just leave it up to the EDA tool to make logical sense out of it then? - Randy probably has the most experience with power aware simulations. - At one point a while ago his models only did power distribution, not ground. I'm not sure if it was for some of these reasons. - Randy: If we do anything with s-parameters then ground is the reference for everything. - For anything with s-parameters the ground distribution is wrapped up into power and signal models. - For the older style RLC models we usually had ground parasitics included. - Walter: I don't know how power aware simulations were done with RLC models. - Randy: If you've got the parasitics for power and ground and all the coupling between them and you get everything referenced properly then it's ok. - Bob: When we make assumptions that the supply has changed, we have to distinguish whether the change is due to purposefully resetting the voltage (DC supply change) or whether we are dealing with ripples. - I'm assuming DC changes, but I'm questioning whether an 0.5V shift is realistic as a purposefully applied change. - Walter: We are talking about GHz devices. - Power distribution tends to be 1 or 2 orders of magnitude lower frequency. - So one could have fluctuations on the power rail that instantaneously look like DC to the device. - So the power rail could look like it had a DC half volt shift as far as the part is concerned. - If you have a wide data bus and happen to be sending obnoxious patterns you could be drawing from the supply at a much lower frequency than your data rate and induce large swings in the supply. - Memories are not that bad because you only have 4 or 5 drivers (DQ and DQS). - On a controller with 128 bit wide DQ, with weird patterns I'm not sure what kind of power distribution values one could have in reality. Are the ripples mV or tens of mV or hundreds of mV? - Randy: You could see 100mV, that's not out of the question. - You supply that current instantaneously from the on-die decoupling when you have a high current demand, and your voltage will drop with that spike of current needed to charge up that capacitance. - Walter: People designing packages will want to dissect this carefully. - People who design systems will take all this power supply noise and stick it into the margins on their device and not worry about power aware simulations. - People try to isolate these detailed simulations from the end users. - Bob: If this is a dynamic voltage shift at significantly lower frequency, then one can't use a [Model Selector] to switch in alternative models. - The [Model] may fail if some switching occurs outside the thresholds because of all of the modulation. - Walter: The question is, can the EDA tool dynamically change the thresholds properly? - What we do in this situation is we never use absolute voltages. They are always relative to the local supplies. We understand how to do that. - Do we have to have IBIS tell EDA tools how to do that? - Bob: I don't know. - Are we overreaching, especially when we deal with ground supply modulations? - We have issues with standard Vinl and Vinh for CMOS. - CMOS supports both bipolar thresholds and the approx. 70% and 30%. - One I/O buffer input can support two different rules that are incompatible. - For example, if it's 0.8V and 2.0V for bipolar but it's a CMOS technology then that remains relatively fixed whether or not the + or - VCC changes 10%, but it might be shifted based on the ground reference. - For CMOS it's spread between 30 and 70% - I'm not sure how much effort we should put into this. It's already pretty complex, and it's supposed to mimic what's in a data sheet. - D.C. Sessions, when he was active in the DDR committees, proposed some of this stuff based on the JEDEC committee at that time. - Arpad: We are over time now. - This is a good summary. We need to think it through carefully. - We need to come up with a recommendation on how we proceed and what we fix. - Walter: Michael Mirmak is going to propose a paragraph to be put at the beginning of IBIS to address this. Maybe that will nicely cover this so we don't have to make editorial changes everywhere. - Arpad: Is he aware of the contents of the presentation you made today? - Will his text handle what you've discovered here? - Mike L.: We can bring this up in the editorial group on Friday. - Arpad: Thank you all for joining. ------------- Next meeting: 26 April 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives